Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-136.txt

Text File | 1994-12-08 | 41.6 KB | 1,145 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 07 Jul 92       Volume 1 : Issue 136

Today's Topics:

    Zooming windows: determining if window is in zoomed state
    Programatically alter Finder menus?
    Slow AppleEvents (was Re: Think C vs. MPW)
    List Manager Bug?
    redirecting keyboard events
    Lempel-Ziv compression question
    Perl with (and without) MPW
    Is Zortech C++ Available For Mac Yet?
    Newcomer questions -- some stuff about a possible programming project
    Passing info between apps
    Where should help files be kept?



-------------------------------------------------------

From: [e-mail] (Peter Broardribb)
Subject: Zooming windows: determining if window is in zoomed state
Organization: DIALix Services, Perth, Western Australia
Date: Sat, 30 May 92 08:21:10 GMT

HIN 006 says: "Before closing a movable window, check to see if its location
or size have changed. If so, save the new location and size. If the window
can be zoomed, save the user state and also save whether or not the window
is in the zoomed (standard) state. ..."

How do you determine if a window is in the zoomed (standard) state?

PETE


+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Mon, 1 Jun 1992 16:38:50 GMT

In article <[e-mail]>, [e-mail] (Peter Broardribb) writes:

> HIN 006 says: "Before closing a movable window, check to see if its location
> or size have changed. If so, save the new location and size. If the window
> can be zoomed, save the user state and also save whether or not the window
> is in the zoomed (standard) state. ..."

> How do you determine if a window is in the zoomed (standard) state?

I'm not claiming this code is perfect, but it was my own hack at this.
This program has four kinds of windows, of which three are fixed size
so only LIST windows can be resized at all.  All windows are implemented
as modeless dialogs.

#define TOPLEFT(aRect)    (* (Point *) &(aRect).top )
#define BOTRITE(aRect)    (* (Point *) &(aRect).bottom )
#define RECTWIDE(aRect)    ( (aRect).right - (aRect).left )
#define RECTHITE(aRect)    ( (aRect).bottom - (aRect).top )

/* Window zoom processing (only LIST windows).
 */
dozoom(WindowPtr windp,short part)
{
    Rect    wrect;

    if ( LDLOG == windowtype(windp) ) {
        SetPort(windp);
        if (inZoomOut == part) {
            getstdstate(windp,&wrect);
            (** (WStateData **) (*(WindowPeek)windp).dataHandle ).stdState = wrect;
            }
        ZoomWindow(windp,part,true);
        sizeuserlist(windp);
        InvalRect(&windp->portRect);
    }
}

This code does compute the "standard" state but it relies on the window
manager's tracking of zoomed in/zoomed out which is probably not right.
The right thing to do is probably to compare the current window size
against the "standard" size (with an 8 pixel slop!).


/* Compute "standard state" for resizable (list) window.
 * This is used by the zooming stuff.
 */
getstdstate(WindowPtr windp, Rect *wrect)
{
    Rect    rect;
    GDHandle    thegd, maingd;

    getnaturalsize(windp,wrect);
    if (colorqd) {
        thegd = nil;
        getmonitor(TOPLEFT(*wrect),&thegd);
        if ( (nil==thegd) || !PtInRect(BOTRITE(*wrect),&(**thegd).gdRect) ) {
            thegd = maingd = GetMainDevice();
            getmaxmonitor(wrect,&thegd);
            rect = (**thegd).gdRect;
            rect.top += 16;
            if ( maingd == thegd )
                rect.top += GetMBarHeight();
            InsetRect(&rect,5,5);
            OffsetRect(wrect,rect.left-(*wrect).left,rect.top-(*wrect).top);
            if ( (*wrect).bottom > rect.bottom)
                (*wrect).bottom = rect.bottom;
            else
                OffsetRect(wrect,0,(RECTHITE(rect)-RECTHITE(*wrect))/3);
            if ( (*wrect).right > rect.right)
                (*wrect).right = rect.right;
            else
                OffsetRect(wrect,(RECTWIDE(rect)-RECTWIDE(*wrect))/2,0);
        }
    } else {
        rect = qd.screenBits.bounds;
        if ( !PtInRect(BOTRITE(*wrect),&rect) ) {
            rect.top += 16 + GetMBarHeight();
            InsetRect(&rect,5,5);
            OffsetRect(wrect,rect.left-(*wrect).left,rect.top-(*wrect).top);
            if ( (*wrect).bottom > rect.bottom)
                (*wrect).bottom = rect.bottom;
            else
                OffsetRect(wrect,0,(RECTHITE(rect)-RECTHITE(*wrect))/3);
            if ( (*wrect).right > rect.right)
                (*wrect).right = rect.right;
            else
                OffsetRect(wrect,(RECTWIDE(rect)-RECTWIDE(*wrect))/2,0);
        }

    }
}

The "natural size" is the size of the window if there were no absolute
constraints on the monitor size (if we had an infinitely huge monitor).

We find the monitor containing the top left of the window.  If the
natural size fits on this monitor, then the natural size is just
returned as the standard size.  We don't need to zoom in this case.
(This is the new System 7 zooming standard...)

If BOTRIGHT is *NOT* on this monitor, we find which monitor contains
most of the window's area (routine getmaxmonitor).  We will try to zoom
to this monitor.  We check to see if the window can be made to fit on
on this monitor (actually within a rectangle 5 points indented on all sizes,
 also indented by menu bar iff this is main monitor).

If it can be made to fit on this monitor by moving the top left corner,
we try to center it left/right and put it 1/3 of the way down from the
top.  If it cannot be made to fit, we truncate standard size down to
the actual size available on this monitor.  This computation is done
independantly on the height and width.  The "else" part is basically
the same thing when there is no color QD (so there is only one screen).


/* Get Graphics Device for monitor containing specified point.
 */
getmonitor(Point thept, GDHandle *thegd)
{
    GDHandle gd;

    if (colorqd) {
        for (gd=GetDeviceList(); nil!=gd; gd=GetNextDevice(gd) ) {
            if ( TestDeviceAttribute(gd,screenDevice) &&
                 TestDeviceAttribute(gd,screenActive) &&
                 PtInRect(thept,&(**gd).gdRect)
               )
                (*thegd) = gd;
        }
    }
}

This is used to get the monitor containing the top left of the window.
If there is no color QD it does nothing at all.  BTW all these
TestDeviceAttribute calls are probably overkill.


/* Get Grapics Device for monitor with max intersection
 * area with specified rectangle.
 */
getmaxmonitor(Rect *wrect, GDHandle *thegd)
{
    int        area, maxar;
    Rect    rect;
    GDHandle    gd;

    if (colorqd) {
        maxar = 0;
        for (gd=GetDeviceList(); nil!=gd; gd=GetNextDevice(gd) ) {
            if ( TestDeviceAttribute(gd,screenDevice) &&
                 TestDeviceAttribute(gd,screenActive) &&
                 SectRect(wrect,&(**gd).gdRect,&rect)
               ) {
                area = RECTHITE(rect) * RECTWIDE(rect);
                if (area > maxar) {
                    maxar = area;
                    (*thegd) = gd;
                }
            }
        }
    }
}

/* Get the natural (zoomed) size of a window.
 * For anything but a list window this will be its current size.
 */
getnaturalsize(WindowPtr windp, Rect *wrect)
{
    ListHandle lhand;

    getwindowrect(windp,wrect);
    if (LDLOG == windowtype(windp) ) {
        lhand = (* (lwptr) windp).lhand;
        (*wrect).right = (*wrect).left + (*(lwptr) windp).maxwid + 16 + 5 + 5;
        (*wrect).bottom = (*wrect).top +
            (**lhand).dataBounds.bottom * (**lhand).cellSize.v + 16 + 5 + 5;
    }
}

This is pretty much specific to the application.  A LIST window contains a
list-manager list, so the natural size is a size big enough to hold the
entire list (dataBounds.bottom * cellSize.v) plus scrollers and margin...


Sorry about the size of this posting.  I couldn't seem to figure out a way
to do it in less code...


+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 6 Jun 92 03:31:33 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Peter Broardribb) writes:

> HIN 006 says: "Before closing a movable window, check to see if its location
> or size have changed. If so, save the new location and size. If the window
> can be zoomed, save the user state and also save whether or not the window
> is in the zoomed (standard) state. ..."
>
> How do you determine if a window is in the zoomed (standard) state?
>
> PETE

Well, you know the coordinates if the window (you specified them when
you set them), and when you resize a window, you specify its
coordinates...

Jeremiah

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 6 Jun 92 23:36:30 GMT
Organization: Taligent


In article <[e-mail]>
[e-mail] (Peter Broardribb) writes:

> HIN 006 says: "Before closing a movable window, check to see if its location
> or size have changed. If so, save the new location and size. If the window
> can be zoomed, save the user state and also save whether or not the window
> is in the zoomed (standard) state. ..."
>
> How do you determine if a window is in the zoomed (standard) state?
>
> PETE

First, get two rectangles. Get the window's portRect and convert it to global
coordinates. Then get the stdState rect from the WStateHandle in the
WindowRecord (the WStateHandle is stored in the WindowRecord's dataHandle field
on windows with a zoom box). That rectangle expresses the size and location of
the window in global coordinates when it is zoomed.

What you want to do next is see if the current portRect is close enough to the
zoomed Rect to have the Window Manager think the window is zoomed. This is done
by comparing the coordinates of the two rectangles. According to Inside Mac IV
(page 10, I think), if the current rectangle is within 7 pixels of the zoom
rectangle, then the window is considered zoomed.

The easiest way to perform this comparison is to form a rect from the top-left
corner of the zoomRect, call Inset(-7, -7), and then pass the resulting
rectangle to PtInRect, with the top-left corner of the of the currentRect as the
Point parameter. If PtInRect() returns TRUE, perform the same test on the
lower-right corner. If the second test returns TRUE, then the window can be
considered in the "zoomed" state.

If you check the standard WDEF proc (posted on ftp.apple.com), you'll see that
that's pretty much how the system makes the same determination.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: Cameron Esfahani <[e-mail]>
Subject: Programatically alter Finder menus?
Date: Sat, 06 Jun 92 02:34:36 EDT
Organization: caen

Does anyone know if it is possible to programatically alter the Finders'
menus?
I am writing an init which would change the text of some menu items.  The
problem
is that I can't access the menu handles.  GetMenu wants to have the menus
be in
a 'MENU' resource and the Finder has it's menusin 'fmnu'.  Does anyone
have any
suggestions?

Thanks,

Cameron Esfahani

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 6 Jun 92 23:40:17 GMT
Organization: Taligent

In article <-Z#[e-mail]>, [e-mail] (Cameron Esfahani)
writes:
>
> Does anyone know if it is possible to programatically alter the Finders'
> menus?
> I am writing an init which would change the text of some menu items.  The
> problem
> is that I can't access the menu handles.  GetMenu wants to have the menus
> be in
> a 'MENU' resource and the Finder has it's menusin 'fmnu'.  Does anyone
> have any
> suggestions?

I know that the INIT "The Grouch" does this. It patches MenuSelect, and sets up
the menus the way it wants them before proceeding to the real MenuSelect code.
You might want to disassemble it and see if it helps you out.

Getting the menu handles is not tough. Just call GetMHandle. That returns to you
a real, live menu handle that exists in the menubar. This assumes that you can
get away with setting the menu items on the fly, and don't need to munge the
'fmnu' resources.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Slow AppleEvents (was Re: Think C vs. MPW)
Date: 2 Jun 92 19:52:34 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> Anyway, my point was that I don't see a future where AEs carry around file
> information, instead pointers where to fetch the data (file system yak,
> data base, better, object oriented database with persistant data, future).

Another thing you can do right now (for those needing to pass large amounts
of data) is pass across a PPC port specification in an AppleEvent, and use
that to establish a connection which is used for higher-speed data transfer.

At least, that's the network-transparent way.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
I'm not fond of benchmarks. I prefer my schmarks to be straight.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 2 Jun 92 19:03:29 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ac.nz> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

   > Anyway, my point was that I don't see a future where AEs carry around file
   > information, instead pointers where to fetch the data (file system yak,
   > data base, better, object oriented database with persistant data, future).

   Another thing you can do right now (for those needing to pass large amounts
   of data) is pass across a PPC port specification in an AppleEvent, and use
   that to establish a connection which is used for higher-speed data transfer.

Why carry it around ? Just check the return address targetID...

- --
h++ - new and improved ! And now on VACCATION !!!
(My first for, oh, three years !)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Jun 92 01:50:28 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
>
> In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> > Anyway, my point was that I don't see a future where AEs carry around file
> > information, instead pointers where to fetch the data (file system yak,
> > data base, better, object oriented database with persistant data, future).
>
> Another thing you can do right now (for those needing to pass large amounts
> of data) is pass across a PPC port specification in an AppleEvent, and use
> that to establish a connection which is used for higher-speed data transfer.

True, this is the way DTS separates the use of PPC and AEs, PPC for the
grunt work (forwarding of huge data segments, sound, video conferences,
quicktime movies) while AEs are the smart intelligent messages telling
applications what they should do.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Fri, 5 Jun 92 13:38:56 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Lawrence
>D'Oliveiro, Waikato University) writes:
>>
>> Another thing you can do right now (for those needing to pass large amounts
>> of data) is pass across a PPC port specification in an AppleEvent, and use
>> that to establish a connection which is used for higher-speed data transfer.


OK, does anyone have some sample code that does this? I was able to plow through
the AppleEvents chapter in I-M 6 (after about three readings), but using the
PPC Toolbox looks... well, much more dense...

If it is on ETO or a developer disk and I haven't seen it yet, just give a
pointer to it. (or a handle... : )


- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 7 Jun 92 00:55:23 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Paul Potts) writes:
> OK, does anyone have some sample code that does this? I was able to plow
through
> the AppleEvents chapter in I-M 6 (after about three readings), but using the
> PPC Toolbox looks... well, much more dense...

> If it is on ETO or a developer disk and I haven't seen it yet, just give a
> pointer to it. (or a handle... : )

Check for the samples on developer CD, under System 7 samples. For instance
the Kibitz sample should have working PPC C code. These samples are also
on the ftp.apple.com server.
- --
                                              Cheers, Kent


---------------------------

From: [e-mail] (Jon Pugh)
Subject: List Manager Bug?
Date: 3 Jun 92 21:16:11 GMT
Organization: Apple Co.

I've noticed this one years ago and I was just reminded of it by NewsWatcher,
which uses the List Manager.  It also shows up in Standard File.

Double click on a list item but hold the second click down without letting it
up.  Now drag, changing the selected item.  When you let up, it will think
you double clicked on the last item selected.

In Standard File under system 6.0.x you can even drag to the scroll bar and
let it up for weirder results.  SFGetFile will return with good = true but
no file name.  It screws up almost everyone.  This part was fixed in 7.0.

I think the dragging is fine, but I think you ought to only get a double
click if you start the double click on the same item you finish it on.

Just thought I would whine about it again.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Owen M. Hartnett)
Organization: Brown University Department of Computer Science
Date: Sat, 6 Jun 1992 00:59:41 GMT

Hey! Let's bash the List Manager!!

Not only that, but if you mouse down and drag, it thinks that the selection
is the thing that you moused down on, but the visual selection (the highlighted
cell) is where you let up on.

Hold it!  The List Manager Demands Equal Time!!!

The List Manager Anti Defamation Society would like to point out, in the
List Manager's defense, that it is perfectly capable of handling lists
with 18,000 records or so, provided that you don't store the data in the
list.

I have done this, and lived to tell of it.

- -Owen
Both Friend and Foe to the List Manager
Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary

---------------------------

From: [e-mail] (Mike Smithwick)
Subject: redirecting keyboard events
Organization: SF-Bay Public-Access Unix
Date: Thu, 4 Jun 1992 01:07:03 GMT

[]

I open up a small modeless dialog and find that in order to get it to accept
any events the mouse pointer must be over the window. Not very handy for
some small windows which can be controlled entire by the keyboard. This
forces the user to grab for the mouse and move it over the panel more
than he should, defeating the purpose of default buttons, etc.

It stands to reason that the window that is active SHOULD be the one receiving
events, but I guess that's not the case. So is there anyway to force this?


mike

- --
"There is no problem too big that can't be solved with high explosives"-Rush

Mike Smithwick - ames!zorch!mike


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 4 Jun 92 20:06:53 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Mike
Smithwick) writes:
>
> I open up a small modeless dialog and find that in order to get it to accept
> any events the mouse pointer must be over the window. Not very handy for
> some small windows which can be controlled entire by the keyboard. This
> forces the user to grab for the mouse and move it over the panel more
> than he should, defeating the purpose of default buttons, etc.
>
> It stands to reason that the window that is active SHOULD be the one receiving
> events, but I guess that's not the case. So is there anyway to force this?
>

You should probably post the relevent parts of your source code. Your conclusion
that the cursor has to be over the dialog is incorrect. A dialog can accept
events no matter where the mouse is.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Roy Wood)
Subject: Lempel-Ziv compression question
Date: 30 May 92 13:58:20 GMT
Organization: International Shared Information Service (Ottawa)

I'm trying to port the Lempel-Ziv compression routine to the Mac for a
program I'm working on, and I'm having a bit of trouble.  Basically, the
uncompress code works correctly 98% of the time-- but there's that annoying
2% of the time when it doesn't!  I've looked over the code for a couple of
days, but I'm stumped.  Does anyone have any ideas what *might* cause such a
spurious error?  It's not the compressed file-- that definitely is not
corrupted (I've checked).

Alternatively, has anyone already written this code?  And would you be
willing to share a copy with me?

Thanks....

- -Roy Wood

+++++++++++++++++++++++++++

From: [e-mail] (Dawson Dean)
Date: 4 Jun 92 21:26:56 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

>I'm trying to port the Lempel-Ziv compression routine to the Mac for a
>program I'm working on, and I'm having a bit of trouble.  Basically, the
>uncompress code works correctly 98% of the time-- but there's that annoying
>2% of the time when it doesn't!  I've looked over the code for a couple of
>days, but I'm stumped.  Does anyone have any ideas what *might* cause such a
>spurious error?  It's not the compressed file-- that definitely is not
>corrupted (I've checked).
>
>Alternatively, has anyone already written this code?  And would you be
>willing to share a copy with me?

You don't give a good description of your problem, so it may be anything.
I had a few problems writing lzrw like this, but they usually ended up
something weird like the dictionary overflowing.

Have you tried lzrw? That's a variation of lzw written by Ross Williams
that is very good. I think that there are now 5 versions (lzrw1, ..., lzrw5)
which make various tradeoffs of speed and compression ratio. Basically,
if you want it to be blindingly fast you sacrifice some compression.

Anyway, the source for all of these are available, and you can get versions
in C or 68K assembler (I think he used Think C 4.0 for the C version,
but I'm not sure and it doesn't matter since he used standard C).
You can check archie for archives, but the official archive is shown below...


Here is the README file that is distributed with lzrw....

- ------------------------------------------------------------------------

DATA COMPRESSION DIRECTORY
==========================
Date   : 04-Apr-1992.
Author : Ross Williams ([e-mail])

This file gives an overview of the data compression directory of the
anonymous ftp archive located at the University of Adelaide, South
Australia. The exact location of the directory is:

   Machine   : sirius.itd.adelaide.edu.au    [IP=129.127.40.3]
   Directory : pub/compression

The directory mostly contains public domain data compression
algorithms developed by Ross Williams during early 1991. It also
contains one or two other items of interest.

The files in this directory may be compressed. Files that are
compressed will have names terminating with ".Z" and will have to be
uncompressed before use (using the Unix "uncompress" command). I
wouldn't trust my files to a data compression algorithm :-), but the
system programmer who put the files there for me (I do not have direct
control over this archive) seems to think that it is a good idea.

Ross Williams
21-Aug-1991

0readme         - This descriptive file.
dc_stan_just    - Justification of dc_stan_spec.
dc_stan_spec    - Proposal for data compression interface standard.
dc_stan_stream  - Revised proposed standard.
dcc91_report    - Report on 1991 Data Compression Conference.
fast_copy.68000 - Fast block move routine for 68000 microprocessor.
lzrw1-a.68000   - LZRW1-A algorithm implemented in 68000 assembler.
lzrw1-a.c       - LZRW1-A algorithm implemented in C
lzrw1-a.txt     - Release notes for LZRW1-A algorithm.
lzrw1.68000     - LZRW1 algorithm implemented in 68000 assembler.
lzrw1.c         - LZRW1 algorithm implemented in C.
lzrw1.tex       - DCC91 conference paper describing LZRW1 algorithm.
lzrw2.c         - LZRW2 algorithm implemented in C.
lzrw2.txt       - Release notes for LZRW2 algorithm.
lzrw3-a.c       - LZRW3-A algorithm implemented in C.
lzrw3-a.txt     - Release notes for LZRW3-A algorithm.
lzrw3.c         - LZRW3 algorithm implemented in C.
lzrw3.txt       - Release notes for LZRW3 algorithm.
lzrw4.txt       - Description of LZRW4 algorithm (not yet implemented).
lzrw45_covering - Release notes for LZRW4 and LZRW5 descriptions.
lzrw5.txt       - Description of LZRW5 algorithm (not yet implemented).
lzrw_headers.h  - Header files (.h files) for C code.
puzzlebox_provpatent - Provisional patent for puzzle box.
rw_info         - Information about Ross Williams and his activities.

WARNING: A patent has recently arisen that may cover one or more of
these algorithms. Please refer to the file rw_info for more
information.

- --<End of 0readme file for the compression directory>


- --
******************************************************************
Dawson Dean                       Internet: [e-mail]
Dept. of Computer Science         Office:   [phone]
Cornell University

---------------------------

From: [e-mail] (Michael Orr)
Subject: Perl with (and without) MPW
Organization: University of Washington
Date: Thu, 4 Jun 1992 06:14:57 GMT

I have received several requests regarding where the macPerl is
located, so I am going to post the information.  I got this off
Archie:

Host nic.switch.ch

    Location: /software/mac
      DIRECTORY drwxrwxr-x        512  Jan 24 16:32  perl

This appears to be the only site that has it (not sumex, not any of
the usual places).  Perhaps someone who is familiar with the upload
process could forward it to the usual macSites so that this poor site
won't be jammed full.  It includes MPW code and a standalone version.
The standalone version is apparently very limited.  I have not had an
opportunity to run either of them yet.  But I am excited to be able to
try out Perl, which I am learning on a unix system, on my very own mac.

Mike Orr  ([e-mail])
"Heroes in a half-shell... Perl power!" :)

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Thu, 4 Jun 1992 12:24:39 GMT

In article <[e-mail]> [e-mail] (Michael Orr) writes:
>I have received several requests regarding where the macPerl is
>located, so I am going to post the information.

Time for another shameless plug, then...

>I got this off
>Archie:
>
>Host nic.switch.ch
>
>    Location: /software/mac
>      DIRECTORY drwxrwxr-x        512  Jan 24 16:32  perl
>
>This appears to be the only site that has it (not sumex, not any of
>the usual places).

There are at least two more sites who have it:

Host wuarchive.wustl.edu
File mirrors/rascal.ics.utexas.edu/programming/Perl_402_MPW_CPT_bin

Host toklab.ics.osaka-u.ac.jp (Probably not a good idea to go there, though)
File /mac/info-mac/info-mac/new1992/01/Perl_402_MPW_CPT_bin

There used to be a site in Sweden also, but this one shouldn't be accessed
from the US (For nic.switch.ch, this is not such a big problem).

>Perhaps someone who is familiar with the upload
>process could forward it to the usual macSites so that this poor site
>won't be jammed full.

I must admit I was somewhat lazy, so I only distributed it to sites with
ftp upload capability. Also, the current version suffers from bad packaging.
Most sites are not exactly delighted about an 1.6M binhex archive of some
obscure Unix programming language.

I'll take offers from ftp sites any time, though :-)

>The standalone version is apparently very limited.

Definitely. Essentially a pure batch thing.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
   "ARGV:  What you say to the dentist when the Novocaine isn't working"
                                   -- Larry Wall, _Programming Perl_

---------------------------

From: [e-mail] (Josh Lam)
Subject: Is Zortech C++ Available For Mac Yet?
Date: 4 Jun 92 20:08:07 GMT
Organization: Honeywell Air Transport Systems Division

Hi,

I understand that Zortech is now under Symantec and recently in the
newsgroups there were mentioned about Zortech C++ on Mac.

Is the Zortech C++ compiler available for the Mac yet?  If it is and if
someone has used it, I would really appreciate any comments on it.

Thanks!


- --
Josh Lam
Honeywell Inc
[e-mail]

+++++++++++++++++++++++++++

Organization: University of Maine System
Date: Thursday, 4 Jun 1992 22:48:27 EDT
From: <[e-mail]>


In article <[e-mail]>,
[e-mail] (Josh Lam) says:
>
>Hi,
>
>I understand that Zortech is now under Symantec and recently in the
>newsgroups there were mentioned about Zortech C++ on Mac.
>
>Is the Zortech C++ compiler available for the Mac yet?  If it is and if
>someone has used it, I would really appreciate any comments on it.

Yes, Symantec's Zortech C++ v2.1 for the Macintosh was released early
this year.  According to our vendor, version 3.0 or something like it
was supposed to be released by early summer, but since we have not
received it, I cannot say for sure.  I can (and will) comment on v2.1,
however.

As you may know, Zortech C++ for the Mac runs inside Apple's MPW shell,
which will set you back over $200 if you buy both the command shell and
the SADE debugger.  Without the shell, Zortech is useless, and without the
debugger, you may find it difficult to cope.  If you have not used the MPW
shell before, be advised that it is one of the most un-Mac like programs
I've ever used.  It relies heavily on command line control.  A UNIX user
would feel right at home.  As far as the Zortech compiler is concerned,
I am told that it is faster that MPW C, can compile C++ (native code) and
ANSI C, and is compatible with SADE.  I cannot say more about the Mac
product as I prefer THINK C 5.0 for Mac development, as it seems faster
and far simpler.  If you need real C++ though, Zortech seems to be the
compiler of choice.

One last note:  I HAVE used Zortech on DOS machines, and liked it a lot.
It was powerful, fast, and flexible, and was ATT C++ compliant (or whatever).
Having a great deal of faith in Symantec, I would say the Mac version is
probably about as good, except for the interface.

- ----------------------------------------------------------------
Todd Rowell
"I ache, therefore I am.  Or in my case I am, therefore I ache."
 - Marvin, the Paranoid Android

                    if("Todd Rowell" == [e-mail])
                        exit(0);
- ----------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 5 Jun 92 05:17:44 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] writes:
>One last note:  I HAVE used Zortech on DOS machines, and liked it a lot.
>It was powerful, fast, and flexible, and was ATT C++ compliant (or whatever).
>Having a great deal of faith in Symantec, I would say the Mac version is
>probably about as good, except for the interface.

       Sadly, no.  The DOS product is excellent.  The Mac product is awful.
I've posted in detail on this subject in the past.

                    John Nagle

---------------------------

From: [e-mail] (The Idealistic Cynic)
Subject: Newcomer questions -- some stuff about a possible programming project
Date: 4 Jun 92 17:43:32 GMT
Organization: AT&T Bell Labs, Columbus, Ohio


Ok's here what's going on (sort of):

A friend of mine and I are considering taking on a project
to developement graphic adventure style educational games.

The problem is that while we're both professional programmers,
and have each had experience on some type of PC and windowing
system, we're not familier with Mac's, nor do we know much
about writing software that does good things with animation.

As a preliminary to a meeting we'll be involved in, we'd like
to ask a few (hopefully) simple questions.

In answering the questions, please keep in mind that while this
is being funded by outside people, it is also being funded by
a University, and they aren't going to want to buy more hardware
or spend more money than they absolutely have to.

    1) What might be considered a minimum hardware
       configuration for developement of a graphic
       adventure game?

    2) We're both C/Unix programmers professionally; what
       version of C would would be a good choice?  Are there
       other languages we should consider?

    3) What are the best books on doing graphics and graphics
       animation on the Mac?

    4) In browsing the group I noticed a post that seemed to
       indicate that there are Unix-type tools available.  Is
       this true?  If so, it would probably cut developement time
       for the initial demo down some.

    5) Lastly: Considering that

        a) We are both competant programmers, familier with
           several languages

        b) Neither of us has done *any* programming work on a
           Mac before

       Do you believe that three months is too short of a time to
       produce a smal, yet functional, demo?  (Say, 5 "rooms", the
       character able to walk around inside the rooms directed by
       the mouse, a couple of puzzles, and maybe a second, computer
       controlled character to talk to once.)

I'll keep watch on this group for a while, but would prefer you email
to either myself (address below) or to Bill Stoll at the following
address:

    [e-mail], [e-mail]

Thanks for your input,

Sean.

- ---
Sean L. Gilley
att!cblph!sunray!slg,   slg@sunray[.cb].att.com,  attmail!sgilley
614 236 5031 (h), 614 860 5743 (w)

+++++++++++++++++++++++++++

From: [e-mail] (David Simmons)
Date: 4 Jun 92 23:00:35 GMT
Organization: Los Alamos National Laboratory

In article <[e-mail]>, [e-mail] (The Idealistic Cynic) writes:
|>
|> Ok's here what's going on (sort of):
|>
|> A friend of mine and I are considering taking on a project
|> to developement graphic adventure style educational games.
|> [stuff deleted...]
|>         a) We are both competant programmers, familier with
|>            several languages

English, apparently, not being one of them. ;-)

- --


David G. Simmons
[e-mail]

"Any resemblance to real opinions is purely coincidental"

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"My ethicator machine must've had a built-in moral compromise spectral
release phantasmatron!  I'm a genius!"

"Another casualty of applied metaphysics"

        Calvin & Hobbes (respectively)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

---------------------------

From: [e-mail] (Peter YANDELL)
Subject: Passing info between apps
Date: 5 Jun 92 03:29:44 GMT
Organization: Computer Science, University of Melbourne, Australia


    I want to develop a pseudo command line for my little SE/30.  To do this I
need to be able to pass information backwards and forwards between applications
when they run and terminate.  Anyone with any bright ideas?  I'm working in C
and assembly (THINK C 4.0).

    First of all, I'm running System 6.0.7 and I don't want to here about all
the fancy tricks you can do with System 7 (tuneup 1.1.1.1.1.1.1.1.1.....) so
don't bother mailing me any ideas along those lines.

    Second requirement is, I have to be able to do it all in memory.  I don't
want to dump the info to be passed to a file on disk, even on a hard disk. Maybe
the speed isn't toooo bad, but I'm against it for religious reasons.

Third, it doesn't have to be Apple correct.  It is NEVER going to get released
and I'm not worried about what it clashes with because it's probably going to be
used under a minimal system anyway.

    On a kind of related point, is there any way to trick my Mac into letting me
open more than one copy of an application at a time?  (Did somebody say Unix?)

    For anyone who's interested, my friend and I are building a machine and
writing an OS for it and I want to use my Mac to do some serious development.
The reason for the command line stuff is, I'm porting public domain compilers
and bits and pieces from all over the place and I need the power of a command
line to link all the bits together and let me download to an EPROM burner.  It
would also mean that I don't have to spend hours converting things to work with
Mac like interfaces.

    Thanks for allowing me this little bit of self-indulgence.  I've just got
into this news stuff and I have to say I'm really enjoying it!


PLEASE E-MAIL REPLIES DIRECTLY TO:

=>     \  /
   Big  \/      -->  [e-mail]  <--
   Pete /
       / .             (OK, so I don't have a real signature!)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Jun 92 23:46:31 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Peter
YANDELL) writes:
>     I want to develop a pseudo command line for my little SE/30.  To do this I
> need to be able to pass information backwards and forwards between
applications
> when they run and terminate.  Anyone with any bright ideas?  I'm working in C
> and assembly (THINK C 4.0).

>     First of all, I'm running System 6.0.7 and I don't want to here about all
> the fancy tricks you can do with System 7 (tuneup 1.1.1.1.1.1.1.1.1.....) so
> don't bother mailing me any ideas along those lines.

>     Second requirement is, I have to be able to do it all in memory.  I don't
> want to dump the info to be passed to a file on disk, even on a hard disk.
Maybe
> the speed isn't toooo bad, but I'm against it for religious reasons.

You could try to reinvent Apple Events!
- --
                                              Cheers, Kent

PS: OK, OK, I'm serious now, a driver which accepts a simple protocol might do
what you want. Load the driver in the system heap, and send information using
Control between the applications. Implement semaphor handling as well!

---------------------------

From: [e-mail] (Nigel Stanger)
Subject: Where should help files be kept?
Date: 5 Jun 92 02:34:09 GMT
Organization: University of Otago, Dunedin, New Zealand

Where is the best place to keep help files? A couple of days ago
I figured out how to put my balloon help and associated stuff
into a separate file (really trivial when you think about it),
and it chops about 15K off the size of the app (quite significant
when the app is only ~65K to start with). At the moment, the help
file has to be in the same folder as the app, which really isn't
that much of a problem, but I was wondering if there was any
"official" place to store these sorts of files? I couldn't see
anything obvious in IM6.

Just as an aside, I was poking around in  when I discovered that
the Finder knows that "Finder Help" is supposed to go in the
Extensions Folder. "Aha!" I thought, "what type of file is it?" I
had a look and it was "help"/"MACS". "AHA!" I thought a bit
louder, "is this a generic help-file type?" Unfortunately, after
a bit of playing around I found that this appears to be the file
type for the Finder Help file itself. If you set the type of any
other file to be "help", turn on balloons and pop the cursor over
the file, you get the balloon for Finder Help! So much for that
idea :(

- --
See ya
                                Nigel.
- ----------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
"I fart in your general direction!" -- Frenchman, MPatHG

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 6 Jun 92 17:40:24 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Nigel Stanger) writes:
>Where is the best place to keep help files?

The System folder (and its subfolders) should contain only files to
be used by the local machine.  Since presumably an application may
be run over a network, don't put the help files there (and please
don't ask me why Finder help is in the Extensions folder.)

In general, keeping a help file in the same folder as the application
or in a subfolder of that directory would be appropriate.  Track it
(perhaps with an alias stored in the prefs file) and, if it can't
be located, do something reasonable (like PBCatSearch, StandardGetFile,
or DebugStr.)

[And to answer the usual code question: an app can find its own location
with GetCurrentProcess/GetProcessInfo, PBGetFCBInfo, GetVol/GetWDInfo, or
your favorite alternative.]

>Just as an aside, I was poking around in  when I discovered that
>the Finder knows that "Finder Help" is supposed to go in the
>Extensions Folder....  If you set the type of any
>other file to be "help", turn on balloons and pop the cursor over
>the file, you get the balloon for Finder Help!

The Finder is from Special-Case City.  System software is _not_ example
code.

Grobbins            [e-mail]

Usual disclaimers apply.


---------------------------

End of C.S.M.P. Digest
**********************